Compatibility considerations for the IDE hook. #1103
Conversation
|
Hi @nedtwigg. I don't have enough knowledge of the IntelliJ SDK know off-hand which would be easier -- I'll have to do some investigation -- but overall I think I prefer option A. It seems like it would provide a better user experience. |
|
@ragurney added Gradle version parsing in ragurney/spotless-intellij-gradle#22. One option to allow the speedup mentioned in 2. above (switching from |
|
@nedtwigg apologies for the belated response. I'm going with option A. I've started the process to make this happen in vscode (see microsoft/vscode-gradle#1156) but haven't had time to chase it up. It's in the works though. |
nedtwigg
added
the
pr-archive
The Spotless IDE hook should just be
spotlessApply -PspotlessIdeHook=${ABSOLUTE_PATH_TO_FILE}. We've had this API since3.30.0, and you shouldn't have to parse a Gradle or Spotless version to use it.But we've got two backward incompatible problems:
Spotless IDE hook is not compatible with the configuration-cache, so you have to specify
--no-configuration-cache. But, that flag is not compatible with Gradle < 6.6. So you're stuck in this position where you have to parse the Gradle version to know whether you need that flag or not.We can speed Spotless up a lot by changing the API to
:spotlessApply -PspotlessIdeHook=BLAH, but only after faster -PspotlessIdeHook with configure-on-demand #1101 gets implemented. So you're stuck in this position where you have to parse the Spotless version to know whether you can add the leading colon or not.We could fix both of those issues by changing the API to this:
:spotlessIdeHook -PspotlessIdeHook=BLAH --configure-on-demandThis fixes problem 1 because Gradle 7.4 adds a new
Task.notCompatibleWithConfigurationCache()method. We can't use that method to fix problem 1 forspotlessApply, but we could use it to fix a new task calledspotlessIdeHook.It also fixes problem 2 because we can change the implementation of
:spotlessIdeHookover time. At first it would trigger the evaluation of all subprojects (likespotlessApplydoes now), but later on it could take advantage of configure-on-demand to speed up execution dramatically.So I have a question for each of you, @badsyntax and @ragurney, which is easier?
A) Parse Gradle and Spotless versions to determine which arguments to use.
B) Optimistically try
:spotlessIdeHookmethod, if it fails fall back tospotlessApply, and then remember "optimistic attempt failed" for the rest of the plugin's runtime. No parsing needed, just detecting an error.As an aside, Spotless is adding support for linters in the medium-term future, and those lints will be available in the IDE hook. We are able to add this information in a backward-compatible way, so it will be optional whether you choose to add support for that in future, no version-parsing or feature-detection required.